Looks like the build fails because Node's "crypto" is not in the browser context. I'm not sure how to handle that without adding a dependency like https://www.npmjs.com/package/crypto-browserify - what's the preference?

The issue existed before with fs/promises (which Vite was externalizing with warnings), but adding crypto makes it worse and causes actual build failures.

So should crypto be replaced with a pure JS implementation or do you have some other preference?

I think the fix has two parts. For this PR, let's focus on the crypto issue:

1. Regarding the shared/modes.ts static import: This is definitely something we need to address, but it's out of scope for this PR. We should remove the top-level import there and instead dynamically import custom-instructions inside getFullModeDetails, but only when cwd is provided. That way it only runs in the extension host and never gets bundled into the webview.

   Something like:

   const { addCustomInstructions } = await import("../core/prompts/sections/custom-instructions")

2. For this PR, We can avoid using crypto entirely. We don't need a cryptographic hash like MD5 just for deduping content.

   We could either use the web-standard globalThis.crypto.subtle.digest("SHA-256", ...) (see MDN), which is async and works in both modern Node and the browser. Or, even simpler, just use a small non-cryptographic hash function like FNV-1a. It's synchronous, pure TS, and has no imports.

This approach means we won't need a polyfill like crypto-browserify.

Also, probably a good idea to update the test names from "MD5" to something more generic like "content hash" so we're not tied to a specific algorithm.

Thanks for the suggestions @daniel-lxs , I removed crypto and added native FNV-1a as you proposed so there are no new dependencies.

I don't think this PR will solve issue #6604 since the injection of the file comes from the CLI itself, outside our logic to load files.

I'll close this PR for now but let me know if something like this makes sense.